Skip to content

[STEP19 & STEP20] 이희망#10

Open
HeeMang-Lee wants to merge 15 commits intomainfrom
step19
Open

[STEP19 & STEP20] 이희망#10
HeeMang-Lee wants to merge 15 commits intomainfrom
step19

Conversation

@HeeMang-Lee
Copy link
Copy Markdown
Owner

@HeeMang-Lee HeeMang-Lee commented Dec 25, 2025

STEP 19 부하 테스트 스크립트 작성 및 진행

  • 부하 테스트 대상 선정 및 목적, 시나리오 등의 계획을 세우고 이를 문서로 작성
  • 적합한 테스트 스크립트를 작성하고 수행

STEP 20 부하 테스트로 인한 문제 개선 및 보고서 작성

  • 테스트를 진행하며 획득한 다양한 성능 지표를 분석 및 시스템 내의 병목을 탐색 및 개선함
  • 가상의 장애 대응 문서를 작성하고 제출함

🔨 작업 내역

[ STEP 19: 부하 테스트 스크립트 작성 및 진행 ]

부하 테스트 계획서 (def970b)

  • docs/13_LOAD_TEST_PLAN.md
  • 테스트 대상 5개 API 선정 (쿠폰 발급, 주문 생성, 결제, 인기 상품, 포인트 충전)
  • SLI/SLO 목표 지표 정의 (TPS > 500, P95 < 500ms)
  • 병목 예상 지점 분석

모니터링 인프라 구축 (7fc6d6a, a25e6a5, d1e550c, a58a666)

  • Prometheus + Grafana 메트릭 수집/시각화
  • Redis Exporter, Kafka Exporter 연동
  • ELK Stack (Elasticsearch, Logstash, Kibana) 로그 수집
  • Pinpoint APM 분산 트레이싱

K6 부하 테스트 스크립트 (958c902, d06a224)

스크립트 목적 패턴
realistic-coupon-spike.js 선착순 쿠폰 스파이크 500→1000 VU 급증
realistic-order-load.js 주문 생성 부하 50→200 VU 점진 증가
realistic-popular-products.js 인기 상품 캐시 검증 100→300 VU
realistic-point-stress.js 포인트 분산락 경합 50→100 VU

Grafana 대시보드 확장 (7479e24)

  • HTTP 요청 히스토그램 메트릭 활성화
  • SLO 기준 응답시간 분포 (50ms, 100ms, 500ms, 1s, 2s, 5s)

[ STEP 20: 부하 테스트로 인한 문제 개선 및 보고서 작성 ]

발견된 문제 및 개선 (d50e480, 343e43a)

문제 원인 해결
서버 다운 (300 VU) Tomcat 스레드 풀 200개 한계 max-threads: 400
DB 커넥션 타임아웃 HikariCP 풀 10개 부족 maximum-pool-size: 50
Redis 락 지연 Lettuce 풀 8개 한계 max-active: 50
인기 상품 API 500 에러 엔드포인트 불일치 /api/products/top 수정
포인트 충전 API 500 에러 RESTful 경로 불일치 /api/points/users/{userId}/charge

서버 설정 튜닝 (application.yml)

server:                                                                                                                                                                
  tomcat:                                                                                                                                                              
    threads:                                                                                                                                                           
      max: 400          # 200 → 400                                                                                                                                    
      min-spare: 50                                                                                                                                                    
    max-connections: 10000                                                                                                                                             
    accept-count: 200                                                                                                                                                  
                                                                                                                                                                       
spring:                                                                                                                                                                
  datasource:                                                                                                                                                          
    hikari:                                                                                                                                                            
      maximum-pool-size: 50   # 10 → 50                                                                                                                                
      connection-timeout: 5000                                                                                                                                         
  data:                                                                                                                                                                
    redis:                                                                                                                                                             
      lettuce:                                                                                                                                                         
        pool:                                                                                                                                                          
          max-active: 50      # 8 → 50                                                                                                                                 

인덱스 최적화 (343e43a)
-- order_payments 복합 인덱스 (스케줄러 쿼리 최적화)
CREATE INDEX idx_status_paid_at ON order_payments (payment_status, paid_at);

-- failed_events 복합 인덱스 (DLT 스케줄러 최적화)
CREATE INDEX idx_status_next_retry ON failed_events (status, next_retry_at);

성능 분석 보고서 (9a6b9f1)

  • docs/14_PERFORMANCE_ANALYSIS_REPORT.md
  • 병목 지점 분석 (Tomcat/HikariCP/Redis/API간 경쟁)
  • Before/After 정량적 효과 측정
  • 추가 개선 권장사항 (Rate Limiting, Circuit Breaker, Auto-scaling)

장애 대응 가이드 (9a6b9f1)

  • docs/15_INCIDENT_RESPONSE_GUIDE.md
  • GitHub/LINE 포스트 모템 형식 적용
  • 가상 장애 시나리오 2건 작성:
    • P1: 블랙프라이데이 주문 폭주 서버 다운 (47분)
    • P2: API 엔드포인트 불일치 기능 장애 (90분)
  • 5 Whys 근본 원인 분석
  • 재발 방지 조치 항목

📊 테스트 결과 비교

시나리오 개선 전 개선 후 효과
주문 부하 ❌ 300 VU 서버 다운 ✅ 200 VU 안정 서버 안정성 확보
인기 상품 ❌ 100% 실패 ✅ 100% 성공, 1,442 TPS API 정상화
포인트 충전 ❌ 100% 실패 ✅ 정상 동작 (분산락 경합 8.4%) 분산락 검증
백그라운드 P95 113ms 50ms 56% 개선
캐시 히트율 0% 70.8% 캐시 효과 검증

🏗️ 아키텍처

모니터링 스택
┌─────────────────────────────────────────────────────────────┐
│ K6 (Load Generator) │
│ │ │
│ ▼ │
│ Spring Boot App ───────────────────────────────────────── │
│ │ │
│ ├── MySQL 8.0 ──────┐ │
│ ├── Redis 7.2 ──────┼── Prometheus ── Grafana │
│ └── Kafka 7.4 ──────┘ │
│ │
│ └── Pinpoint Agent ── Pinpoint APM │
│ └── Logstash ── Elasticsearch ── Kibana │
└─────────────────────────────────────────────────────────────┘

부하 테스트 패턴
Background Traffic (상품 조회) ──────────────────────────────

│ 스파이크/램프업
Target API Traffic ──────────────┴──────────────────────────
시작 피크 종료


🤔 리뷰 포인트

  1. 장애 대응 가이드의 포스트 모템 형식이 적절한지?

간단 회고 (3줄 이내)

  • 잘한 점: 부하 테스트로 실제 병목(스레드/커넥션 풀)을 발견하고 설정 튜닝으로 해결
  • 어려운 점: K6 스크립트 API 경로 불일치로 100% 실패 → 디버깅에 시간 소요
  • 다음 시도: Rate Limiting, Circuit Breaker 적용, Auto-scaling 구성

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant